Networking nowadays

Challenges

Are we ready?

• Multi-vendor with legacy devices not well-suited for automation
• There is a lot of new things to learn
• Vendor trainings aren’t (weren’t) focused on this
• Automation amplify everything (including mistakes)
• Usually, not close to developers, to the business

And most of the times, we don’t know where to start from...

How can we approach it?

• APIs everywhere, your network devices should support them
• Use Data Models, they will help you translate your will
• Take advantage of the information your network is providing
• Don't fear dynamic infrastructure
• Some coding skills will be needed
• Validate, validate and validate again

Start by solving simple problems... keeping applications on your line of sight

A brief story of a network service

Typical IT ecosystem

How the network looks like

Downsides

• By default, inter/intra platform communications use Internet which is not (always) the most performant, secure and cheapest communication channel
• Manual network provisioning doesn’t work in terms of speed and reliability
• Prone to errors and lack of consistency
• Some communications still need network layer security (no TLS)

We tried to solve all in one

... and we failed

(non-technical) Lessons learned

• Think as your users will do
• Get feedback as soon as possible, iterate!
• The solution should flexible enough to accommodate several underlying solutions
• Evaluate current needs case-per-case (capability, performance, cost, etc.)
• Apply Pareto Rule, focus on solving most urgent first

Then, we created a network service

New goal

Requirements

• Easy onboarding / selfserve
• Users should be autonomous to handle connections
• Abstract all network details from users, and pick the best option in every case
• Support several providers/platforms
• Offer a secure service
• Continuous monitoring of connection status

Assumptions

• Mgmt-API users will be authenticated through a SSO / Token
• Permissions to manipulate others' network infrastructure
• External APIs to integrate with
• Consistent address plan (less pain)

Actual implementation

• A rest API
• A distributed asynchronous architecture
• Extensible modules to talk with underlying network services
• Running on dynamic infrastructure (IaaS, PaaS, SaaS)
• Infrastructure as Code and Continous Integration and Deployment

Architecture

Entities

• Service: Abstract container of Providers and Resources, owned by OKTA users
• Provider: Environment/Platform where Resources are deployed
• Resource: A network element defined by the network address (CIDR)
• Connection: Bidirectional link between Resources

Demo

Scenario

If your browser doesn't support the embbeded video format, you can get it from here

Why to use this?

• You don't care about underlying network details
• You always use the best possible network solution
• You have one API to handle any network solution
• You are notified about your connections' health
• You need an out-of-the-box multiple platform connectivity
• You get visibility about your network dependencies

Takeaways

• Don’t be afraid of going out of your comfort zone
• At some point, you will need to join pieces
• Learning coding will give you superpowers
• Adopting a DevOps approach will speed up your business (and career)
• Networking is a key skill in IT, bring it close to the business

Thanks for your attention

Q/A

FAQs

• Any plan to opensource it?
• What's the difference with service mesh?